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ABSTBACT 

This  thesis  presents  a  design  and  partial  implementation 
cf  a  program  family  cf  extended  pretty  printers.  Factors 
that  influence  the  readability  (perception)  and  understand- 
ability  (cognition)  of  computer  programs  are  indennifisd, 
previous  work  is  reviewed,  and  new  solutions  are  suggested. 
Extensicns  to  the  previous  pretty  printer  designs  includa  a 
capability  to  selectively  display  levels  of  control  of  a 
program.  In      order     to        accommodate      different      computer 

languages  and  to  allcw  for  several  secondary  functions,  a 
family  of  pretty  printers  is  designed.  This  design  facili- 
tates  easy   extension,   contraction   and   modification. 
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!•    INTRO DOC Tig N 

Programs  are  written  to  be  read  and  understood  by 
people.  The  textual  representation  should  be  such  that  it 
is  easy  to  read.  That  is,  the  representation  of  the  program 
should  be  such  that  it  reduces  the  visual  burden  on  the  user 
and  allows  him  to  develop  and  exploit  visual  clues  -o  aid  in 
reading.  In  addition,  the  text  of  the  program  should  be 
designed  so  that  it  is  easy  for  the  reader  to  grasp  the 
meaning  of  the  program:  that  is,  the  representation  of  the 
program   should    help    the  reader    understand   the   program. 

Fifteen  years  age  Dijkstra  argued  that  "...  our  intel- 
lectual powers  are  rather  geared  to  master  static  relations 
and  cur  powers  to  visualize  processes  evolving  in  time  are 
relatively  poorly  developed.  For  that  reason  we  should  do 
(as  wise  programmers  aware  of  our  limitations)  our  utmost  to 
shorten  the  conceptual  gap  between  the  static  program  and 
the  dynaiic  process,  to  make  the  correspondence  between  the 
program  (spread  out  in  text  space)  and  the  process  (spread 
out  in  time)  as  trivial  as  possible."  [Ref.  16].  There  is 
an  additional  conceptual  gap  between  the  program  spread  out 
in  text  and  how  we  represent  and  manipulate  the  static 
program  and  its  dynairic  process  in  our  minds.  Here  also  we 
should  try  to  narrow  the  conceptual  gap  so  that  the  program 
is   easy    to    read    and    to  understand. 

In  the  computer  science  literature,  readability  and 
understandability  are  often  used  interchangably .  Readability 
is  related  to  physical  conditions,  for  instance,  the  size, 
type  font,  color,  and  clarity  of  characters,  proper  indenta- 
tions, and  the  spacing  between  lines.  Understandability  is 
related  to  psychological  conditions,  for  instance,  pattern, 
memory,    logic,    and    repetition   learnings.    Precisely    speaking. 
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readability  means  good  perception  and  anderstandabilty  means 
good  cognition.  The  system  that  will  be  designed  in  this 
thesis  will  seek  to  improve  both  readability  and  understand- 
ability  by  means  of  reformatting  computer  programs  and 
presenting  the  user  with  alternative  representations  tc  aid 
understanding. 

There  is  evidence  to  show  that  readability  and  under- 
standability  of  computer  programs  is  an  important  issue  that 
is  directly  related  to  programmer  productivity.  Although 
this  has  been  recognized  for  some  time,  further  improvements 
in  the  textual  representation  of  computer  programs  are 
possible.  This  thesis  will  review  the  previous  work,  analyze 
the    remaining  problems,    and    propose   new   solutions. 
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II.     EXTENDED    PRETTY    PBINTEH 

A.       BACKGBOQND 

In  a  study  of  comnierical  programming  practices,  Elshoff 
[Ref.  5]  found  that  most  programs  wers  poorly  written.  They 
were  very  large,  extremely  difficult  to  read  and  understand, 
and  mere  ccmplex  than  necessary.  Furthermore,  -he  sxudy 
determined  that  programming  language  usage  was  poor  and 
inconsistent.  The  results  of  the  survey  by  Lientz  [Ref.  6] 
show  that  the  quality  of  programming  is  a  generally 
perceived  problem.  There  has  been  a  major  effort  to  improve 
programming  practices.  But  there  still  exist  many  programs 
that  are  difficult  tc  read  and  understand  and  yet  they  must 
regularly   be  corrected  and/ or    modified. 

There  are  many  factors  connected  with  the  readability 
and  understandabilit y  of  a  computer  program.  The  reader's 
familiarity  with  the  program,  knowledge  of  the  application 
area,  and  cwn  programming  style  are  important  factors  that 
are  mcsrly  independent  of  the  program  [Ref.  4].  This  thesis 
is  concentrated  on  the  representation  of  program  text  that 
impacts  its  readability  and  understandabilit y.  \  readable 
program  always  seems  to  exhibit  a  common  set  of  properiies 
[Ref.  8]  [Ref.  9]  [Ref.  10].  The  program  is  well  commented. 
The  logical  structure  of  the  program  is  constructed  from  a 
common  set  of  single-entry  single-exit  flow  of  control 
units.  Variable  names  are  mnemonic  and  references  to  them 
localized.  The  program's  physical  layou-  makes  the  salient 
features  of  the  algorithm  that  is  implemented  stand  out 
[Ref.    14]. 
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since  abstraction  is  an  important  mechanism  that  people 
use  to  understand  programs,  xhe  suppression  of  details  in  a 
program  can  aid  understanding.  Modern  design  methodologies 
include  tcp  down  design  using  stepwise  refinement.  In  this 
methodology,  the  programmer  designs  successive  levels  of  the 
program.  These  levels  are  visible  during  the  design  but  are 
often   not      visible    in  the      final    program.  The    understand- 

ability  of  a  program  can  be  improved  by  making  the  levels  of 
the  program  structure  visible.  It  is  true  that  a  program 
may  have  all  these  properties  and  still  be  unreadable  and 
not    understandable;  however,      the    readability      and    under- 

s^andability  of  a  prcgrara  are  certain  to  suffer  when  it 
lacks    one   or  more  of   the  the   properties   [Ref.    14]. 

B.        DEFINITION 

Rubin  [Hef.  14]  defined  a  pretty  printer  as  follows: 
"It  is  a  software  tool  to  format  programs  to  make  them 
easier  to  read  and  understand."  The  extended  pretty  printer 
can  be  defined  as:  a  software  tool  to  improve  readability 
and  understandability  by  adding  level  documentation, 
commenting  and  reformatting.  These  additional  extensions  to 
pretty  printers  will  aid  people  in  understanding  the  program 
by  making  more  visible  the  structure  of  the  program  and 
supporting  the  viewing  of  the  levels  of  the  program.  The 
primary  function  of  an  extended  pretty  printer  is  to  add 
some  level  documentation  and  comments,  to  insert  spaces  and 
linefeeds  between  tokens  -  character  strings  -  and  to  decide 
where  and  hew  to  break  lines  that  are  too  long  to  fit  on  the 
output   medium. 
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C.       GOALS 

The  methods  for  improving  the  readability  and  ur.der- 
standability  of  a  program  use  a  set  of  specific  transforma- 
tions "Chat  can  be  applied  to  the  program  text.  The 
following  program  tranforma tions  can  be  done  by  an  extended 
pretty   printer. 

1 .      5ef  ormat 

The  consistent  formating  of  programs  is  very  impor- 
tant. Elshoff  [Hef.  14]  said  "Just  as  paragraphing  and 
sectioning  help  written  English,  so  can  indentation, 
keyword  positioning,  and  logical  grouping  aid  a  prograniming 
language.".  Those  jobs  can  be  done  automatically  by  a 
pretty  printer.  It  will  allow  the  program  to  be  read  more 
easily. 

2  •      Add    Lev  el  Structure    Documentation 

In  writing  about  his  experments  on  program  compre- 
hension, Shneiderman  [Ref.  17]  said  "Instead  of  absorbing 
the  program  on  a  character-by-character  basis,  programmers 
recognize  the  function  of  groups  of  statements  and  then 
piece  together  these  chunks  to  form  ever  larger  chunks  until 
the  entire  program  is  comprehended."  This  experiment 
suggests  that  the  level  documentation  (chunks)  of  a  program 
will    help   the  understandability  of  the   program. 

3  •      Standardization 

Standardization  contributes  understandability  of  a 
program.  To  understand  this,  it  is  helpful  to  know  the 
source  of      the    expert   programming*s    capacity.  The    primary 

piece  of  direct  behavioral  evidence  for  this  is 
Shneiderman's  replication  [Hef.  26]  for  programming  of  Chase 
and      Simon's  classic     study      on      memory    for      chess      position 
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[Ref.  27].  In  both  these  studies,  the  experts  in  a  parti- 
cular domain  could  memorize  information  from  that  domain 
(i.e.  a  program  or  a  chess  position)  far  better  than 
novices,  provided  that  the  information  was  appropriately 
structured.  If  the  structure  was  made  random  (by  shuffling 
the  statements  of  the  program  or  rearranging  the  chess 
pieces) ,  the  advantage  of  the  expert  would  be  greatly 
reduced.  That  means  that  the  expert  has  no  better  memory 
than  the  novice,  but  rather  an  elaborate  knowledge  sxructure 
in  terms  of  which  correspondingly  structured  items  can  be 
very    efficiently  encoded  [Ref.    15]. 

If  this  result  is  extended  to  programming,  it 
suggesrs  that  the  expert  programmer  gets  his  better  know- 
ledge of  programs  frcm  visible  program  structure.  As  noted 
above,  if  the  textual  representation  is  not.  structured  (e.g. 
random),  the  expert  programmer  will  lose  part  of  his  capa- 
bility, People  understand  something  better  when  they  can 
integrate  it  with  what  they  already  know.  From  this  view, 
standardization  helps  people  tc  understand  other  people's 
programs  more  quickly.  The  visual  cues  are  important  in 
order  to  unburden  the  program  reader.  The  final  objectives 
of  computer  program  standards  are  to  ensure  consistency, 
reduce  program  development  and  testing  time,  improve  main- 
tainability of  programs,  and  improve  changeability  of 
programs  [Ref.  12].  Programming  standards  are  not  intended 
to  stifle  the  imagination  of  programmers.  Experiments  of 
Godfrey  [Ref.  12]  have  shown  that  standards  simply  remove 
the  drudgery  of  coding  and  allow  programmers  to  concentrate 
more  en  the  problem  at  hand.  It  should  be  noted  that  the 
estabishment  of  standards  is  a  costly  process.  It  should  be 
kept  in  lind  that  prcgramming  standards  are  not  a  panacea 
for  eliminating  all  poorly  written  programs.  Adherence  to 
these  standards  will  not  automatically  produce  'good*  code 
[Ref.    12]. 
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There  are  multiple  levels  of  understanding  a 
program.  It  is  possible  to  follow  each  line  of  code  without 
understanding  the  overall  program  function.  It  may  also  be 
possible  to  understand  the  program  funccion  but  not  under- 
stand each  of  the  steps.  There  is  also  a  middle  level  of 
understanding  concerning  control  structures,  module  design, 
and  data  structures  [Ref.  17].  Skimming  for  a  top  down  view 
is  to  suppress  detail  until  the  overall  program  is  under- 
stood. Then  the  program  is  read  selectively  and  understood 
in  more  detail. 

4 .   Example 

The  following  example  will  show  how  the  reformat- 
ting, level  structured  documentation,  and  the  standardiza- 
tion help  the  readability  and  understandability  of  a 
program. 

The  bubble-scrt  algorithm  will  be  introduced  for 
this  example  [Ref.  18].  The  idea  of  -he  bubble  sort  is  as 
follows:  "We  go  through  a  list  comparing  adjacent  items  and 
exchanging  those  that  are  out  of  order.  During  such  a 
compare-and-exchange  pass,  an  item  moves  forward  in  the  list 
until  it  'bumps  up  against'  a  larger  item."  [Ref.  18].  An 
algorithir  language  [Ref.  18]  and  structured  FORTRAN  will  be 
used    for   this      example. 

TH2    ALGORITHM    FOF    BaEELE_SORT    : 

ALGORITHM     BUBBLE    SORT 
INPUT    N 

INPUT    LIST{1  :N) 
REPEAT 

NO-EXCHANGES    <--    TRUE 
FOR    I    < —     1    TO    N    -    1     DO 

IF    LIST  (I)     >    LISTfl+l)     THEN 
TEMP   <--    LlSiri) 
LIST(I)     <—    LIST(I-H) 
LIST(I+1)     < —    TEMP 
NO-EXCHANGES    <--    FALSE 
END    IF 
END    FOR 
UNTIL    NO-EXCHANGES 
OUTPUT   LIST  (  1:N) 
END   BUBBLE-SORT 

16 


DNFOEMATTED    FOSTBAN    EEOGRAM    FOR    BUBBLS_SORT    : 

INTEGER         LIST  (100)  ,I,N,TEMP 

LOGICAL         NOEXG 

READ(5,100)     N 
100    FORMAT  (15) 

READ(5.100)    LIST 
5    CCNTINUE 

NCEXG    =    .TRUE. 

DO   777    1=1, N-1 

IF  (.NOT.  (LIST(I)  .  GT.LIST(I+1)  )     GO    TO    10 

TEMP    =    LIST(D 

LIST  (I)     =    LIST  (1+  1) 

LISTJI  +  I)     =   TEMP 

NOEXG    =    .FALSE. 
10    CCNTINUE 
777    CONTINUE 


IFr.  NOT.  NOEXG)     GO    TO    5 
WRITE  (6,200).   LIST 
200    FORMAT  (IX,  17) 


STOP 
END 


The  following  shows  some  of  the  possible  outputs  of 
an  extended  pretty  printer.  Indentation  is  used  to  improve 
readability.  Selective  display  of  the  levels  of  the  ccr.rrol 
structure  of  the  prcgram  both  in  FORTRAN  and  in  a  general- 
ized programming  language  is  used  to  support  improved  under- 
standability.  The  reader  selects  the  textual  representation 
that  best  supports  his  current  perceptiuai  and  cognitive 
needs. 

LEVEL   lA    : 

INTEGER         LIST  (100),     I,    N,     TEMP 
LOGICAL  NCEXG 

R  E  AD  ( 5  , 1  0  0 )    N 
READ(5,100)    LIST 
REPEAT 

COMPOUND    STATEMENT 
UNTIL     NOT     NOEXG 
WRITE (6,200)    LIST 

STOP 
100    FORMAT  (15) 
200    FORMAT  (IX,  17) 

END 


LEVEL    IE 


DECLARATION 
DECLARATION 

SIMPLE    STATEMENT 
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SIMPLE    STATEMENT 
R  E  PE  A  T 

COMPODND    STATEMENT 
ENDUNTIL 
SIMPLE    STATEMENT 

STOP 
END 


This  shows  the  first  level  of  bubble  sort  program. 
Here  only  the  repeat  condition  is  represented,  so  the 
reader  of  the  program  can  see  simply  the  highest  level 
structure  of  the  program  and  can  understand  the  overall 
design   of      the    program      more   easily.  The   reader      can   then 

select   presentations     that    show   additional   levels      until   the 
completed   program   is    displayed. 

LEVEL   Ilii    : 

INTEGER         LIST  (100),    I,    N,     TEMP 
LOGICAL         NOEXG 

READ(5,100)     N 
READJS.IOOJ    LIST 
5    CONTINUE 

NOEXG    =    .TRUE. 
FOR    I    =    1    TO    N    -    1 

CCMPOUNC  STATEMENT 
ENDFOR 
IF  (.  NOT.  NOEXG)  GO  TO  5 
WRITE  (6,200)  LIST 

STOP 
100  FORMAT  (15) 
200  FORMAT  (IX,  17) 

END 


LEVEL    HE    : 


DECLARATION 
DECLARATION 

SIMPLE  STATEMENT 
SIMPLE  STATEMENT 
REPEAT 

SIMPLE    STATEMENT 

DC    FOR 

COMPOUND    STATEMENT 

ENDFOR 
ENDREPEAT 
SIMPLE    STATEMENT 

STOP 

END 
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LEVEL    IIIA 


INTEGER         LIST  (100),     1,    U,     TEMP 
LOGICAL  NCEXG 

READ(5,100)    N 
READ(5.100)    LIST 
5    CCNTINUE 

NOEXG    =    .TRUE. 

DO    777    I    =    1  ,    N    -     1 

IF   LIST  <I)     >    LIST(I■^1)     THEN 

COMPOUND    STATEMENT 
ENDIF 
777  CONTINUE 

IF  (.NOT.  NOEXG)     GO    TO    5 
WRITE(6,200)    LIST 

STOP 
100    FORMAT  (15) 
200    FORMAT    IX, 17) 

END 


LEVEL    HIE. 


DECLARATION 
DECLARATION 

SIMPLE  STATEMENT 
SIMPLE  STATEMENT 
REPEAT 

SIMPLE    STATEMENT 
DC    FOR 

IF   CONDITION    THEN 

COMPOUND    STATEMENT 
ENDIF 
ENDFOR 
ENDREPEAT 
SIMPLE    STATEMENT 

STOP 
END 


Fcr  most  exf erisnced  programmers  who  are  familiar 
with  top  down  design  with  stepwise  refinement,  the  following 
representations  are  easier  to  read  and  understand  than  -he 
intial   programs. 

FINAL    SOURCE   PROGRAM    : 

INTEGER         LIST  (100)  , I, N, TEMP 
LOGICAL         NOEXG 
C 

READ(5,100)     N 


READJS-IOO)    LIST 
5    CCNTINUE 

NCEXG  =  .TRUE. 
DO  777  1=1  ,N-1 

IF(. NOT.  (LIST(I) .GT. LIST (1+1)  )  GO  TO  10 
TEMP  =  LIST  (I) 
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LIST  (I)     = 
LIST(I+1) 
NCEXG    =     , 
10  CONTINUE 

777   CONTINUE 

IF  (.  NOT.NOEXG)     GO    TO    5 
WRITE  (6,200)    LIST 

STOP 
100    FCEMAT  (15) 
200    FORMAT    IX, 17) 

END 


LIST  (1+1) 

=    TEMP 
FALSE. 


FINAL    STRUCTURE    DOCUMENTATION    : 

DECLARATION 
DECLARATION 

SIMPLE  STATEMENT 
SIMPLE  STATEMENT 
REPEAT 

SIMPLE    STATEMENT 
DO    FOB 

IF   CONDITION    THEN 

SIMPLE    STATEMENT 
SI MPLE 
SIMPLE 
SIMPLE 
ENDIF 
ENDFOB 
ENDREPEAT 
SIMPLE    STATEMENT 

STOP 

END 


STATEMENT 
STATEMENT 
STATEMENT 
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III.     SOME    iiPROlCHES    AND    VAHIOOS    OBJECTS 

A.       SCHE    AFEBOACHES 

There  hav€        been  many  attempts        to  improv? 

understandafaility   and  readability.    The   following   are   -typical 
examples . 

1 .      Neat er 2 

N€ater2  accepts  a  PL/I  source  program  and  operates 
on  it  to  produce  a  reformatted  version.  When  in  the  LOGICAL 
mode,  it  indicates  the  logical  structure  of  the  source 
program  in  the  indentation  pattern  of  its  output.  A  number 
of  options  are  available  to  give  the  user  full  control  over 
the    output    format  and   to   maximize   its   utility.      [Hef.    19] 

2 •      Prettyprint 

It  takes  as  input  a  Pascal  program  and  reformats  the 
program  according  to  a  standard  set  of  pretty  printing 
rules.  The  pretty  printing  rules  are  given  i.e.,  fixed. 
[Ref.    22] 

3 •      Pascal    Program   Form  atter 

Format  is  a  flexible  pretty  printer  for  Pascal 
programs.  It  takes  as  input  a  syntactically-correct  Pascal 
program  and  produces  as  output  an  equivalent  but  reformatted 
Pascal  program.  The  resulting  program  consists  of  the  same 
sequence  of  Pascal  symbols  and  comments,  but  they  are  rear- 
ranged with  respect  to  line  boundaries  and  columns  for 
readability.      [Ref.    20] 
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The  flexibility  of  Format  is  accomplished  by 
allowing  the  user  tc  supply  various  directives  (options) 
which  override  the  default  values.  Rather  than  being  a  rigid 
pretty  printer  which  decides  how  a  program  is  tc  be 
formatted,  the  user  has  the  ability  to  control  how  format- 
ting is  done,  r.ot  cr.ly  prior  to  execution  but  also  during 
execution  through  the  use  of  pretty  printer  directives 
embedded  in  the  frogiam.   [  Hef .  20] 

4 .  Contour 

It  is  a  prcgram  whose  purpose  is  to  graphically 
illustrate  a  program's  structure.  It  operates  by  bounding 
the  scope  of  loops  and  conditionals  by  solid  (or  nearly 
solid)  lines.  When  ccmpound  statements  are  embedded  in  other 
compound  statements,  one  obtains,  rather  than  confusion,  a 
rather  pleasant  display  reminiscent  of  the  contour  lines  of 
a  topographical    map.      [Ref.    22] 

5 .  Syntax-Directed   Pretty   Printer 

It  is  a  language  independent  pretty  printer.  It  is 
divided  into  two  phases:  the  grammer  processing  phase  and 
the  program  processing  phase.  A  language  grammar  for  the 
specific   language   must   be  provided.  It    is    much    easier   and 

quicker  tc  write  a  grammar  for  a  language  than  to  code  a 
new  pretty  printer  for  a  specific  language.  It  can  work  for 
all  structured  programming  languages,  and  with  minor  modifi- 
cations, can  work  for  other  languages.  It  can  handle  such 
problems   as   comments   and   error    recovery.      [Hef.    14] 

6.  Others 

The  recent  availability  of  low  cost,  high  quality 
computer  printers  allows  additional  opportunities  to  improve 
readability  and  understandability .  Important  characters  or 
words    can    be  represented    with   different    fonts:    for    instance. 


22 


the  keywords  can  be  represented  by  bold  characters  cr  ba 
underlined  to  be  recognized  more  easily  than  other  words. 
This    can   improve  the   readability   of   program. 

B.       VARICOS    OBJECTIVES 

Although  the  final  objective  of  all  approaches  is  to 
improve  the  readability  and  understandabilty  of  the  program, 
there  are  many  secondary  objectives.  The  following  are 
typical    examples  of    them: 

Teaching  structure:  An   automatic      system    that      checks 

structure  and  indentations  can  help  beginning  students  learn 
good      programming      practice.  A   system      that      gives      clear 

corrections  to  mistakes  can  provide  a  student  with  quick 
feedback.  Such  a  system  helps  a  student  to  learn  structured 
programming   and    to    learn   a    set   of   programming  standards. 

Standardization      in     a    programming      organization:  For 

large  software  projects  with  many  programmers,  program 
standardization  is  necessary  to  help  in  communication  among 
programmers. 

Eeformatting  for  maintenance:  There  are  many  programs 
that  are  very  difficult  to  read.  The  maintenance  process 
can  be  helped  if  programs  can  be  transformed  into  a  form 
that      is      familiar      to  the      maintenance      programmers.  Ths 

scoping  capability  of  an  extended  pretty  printer  as 
described  above  can  also  help  programmers  understand 
programs   they  are  correcting   and   modifying. 

Automatic  corrections:  An  extended  pretty  printer  can 
check  the  indentation  of  programs,  correct  indentation 
errors,    and    give  the    user  messages  explaining   the    errors. 
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From  the  above  observations,  several  common  parts  of  the 
existing  approaches  can  be  found.  First,  most  of  the  systsms 
are  for  a  specific  programming  language,  for  ancther 
programming  language  they  would  have  to  be  written  again. 
The  one  exception  is  the  syntex  directed  pretty  printer;  for 
each  new  language  it  requires  a  grammar  for  each  the 
language.  Defining  a  correct  grammar  is  not  an  easy  task. 
Second,  most  of  the  systems  try  to  make  the  pretty  printer 
flexible,  but  the  flexibility  is  limited  to  a  few  options 
and  it  is  not  easy  to  extend  the  requests.  Most  constructs 
cf  the  pretty  printers  are  fixed,  but  the  constructs  them- 
selves can  be  changed  e.g.  extended  or  contracted.  New 
structures    for    indentation    can   be  generated. 
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IV.    PROGRAM    FAMILI 

A.  DEFINITION 

Program  families  are  defined  by  Parnas  [Ref.  13]  as  sets 
of  programs  whose  common  properties  are  so  extensive  that  it 
is  advanxageous  to  study  the  common  properties  of  the 
programs  before  analyzing  individual  members.  Program  fami- 
lies are  analogous  to  the  hardware  families  promulgated  by 
several  manufacturers.  Although  the  various  models  in  a 
hardware  family  might  no-c  have  a  single  component  in  common, 
almost  everyone  reads  the  common  'principles  of  oprarions' 
manual  before  studying  the  special  characterisxics  of  a 
specific    irodel   [Ref.     13]. 

B.  EESIGN    METHODOLOGY 

Parnas  [Ref.  13]  shows  how  module  specifications  define 
a  family.  This  is  an  important  guide  for  selecting  the 
design  method.  Members  of  a  family  of  programs  defined  by  a 
set  of  module  specifications  can  vary  in  three  principal 
ways. 

1.       Implementation    methods    used    wi-hin   the    modules. 

Any  combination  of  sets  of  programs  which  meet  the 
module  specifications  is  a  member  of  the  program  family. 
Subfamilies  may  be  defined  either  by  dividing  each  of  the 
main  modules  into  submodules  in  alternative  ways,  or  by 
using  the  method  of  structured  programming  to  describe  a 
family   of   i aplementa tions  for   the   module. 
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2.  Varia+icn  in  the    external    parameters. 
The    module      specif icati ens  can      be   written 

parameters  so  that  a  family  of  specifications  resul-s. 
Programs  may  differ  in  the  values  of  those  parameters  and 
still   be   considered   to  be  members   of    the   program   family. 

3.  Use    cf    subsets. 

In  many  situations  one  application  will  require  only  a 
subset  of  the  functions  provided  by  a  system.  We  may 
consider  programs  which  consist  of  a  subset  of  the  programs 
described  by  a  sat  of  module  specifications  to  be  members  of 
a   family   as    well. 

As  discussed  above,  there  are  many  primary  and  secondary 
objectives  for  a  pretty  printer.  One  approach  ro  these 
various  demands  would  be  to  design  a  large  program  with  many 
options.  Such  an  approach  has  several  drawbacks:  first,  the 
resulting  program  would  be  large  and  necessarily  complex, 
second,  for  each  specific  use  of  the  program  the  unneeded 
options  will  most  lik«ly  impose  an  unnecessary  computational 
burden.  The  notion  cf  a  program  family  offers  an  alterna- 
tive design.  A  separate  program  will  be  written  for 
different  demands,  however,  all  these  programs  will  share  a 
common  design  and  many  modules  will  be  common  to  several 
family   members. 

The  concept  of  program  families  provides  one  way  of 
considering  program  structure  more  objectively.  For  any 
precise  description  of  a  program  family  (either  an  incom- 
plete refinement  of  a  program  or  a  set  of  specification  or  a 
combination  of  both)  one  may  ask  which  programs  have  been 
excluded  and  which  still  remain  [Raf.  13].  The  criteria  of 
defining  modules  can  be  a  way  to  select  or  distinguish  some 
design    methodologies   [Ref.    3]. 
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C.       FBOGEAMMING    LANGOAGE    FOB    OBJECT    ORIENTED    DESIGN 

fl  design  methodology  alone  is  nor  sufficient  tc  create 
computer  solutions  [ Eef .  3].  Some  features  of  a  programming 
language  can  also  help  in  creating  good  software.  In  the 
following   table,         P.  Wegner   has   categorized    some      of   the 

most    popular  languages   into    genera-ions,      along    with    seme   of 

TABLE    I 
Prograaming  Language   Generation   Table 

languages  Period 

FORTRAN    I,       ALG0L58  1 954    -    1958 

FCHTRAN    II,    ALGOL60  1959    -     1961 

COBOL,    LISP 

PI/I,    ALGOL68,  1962    -    1970 

PASCAL 

1970    -    1980 

the    language  features  they    introduced: 

ACA  was  developed  a-  the  end  of  the  language  genera- 
tion gap,  and  sc  has  been  influenced  by  contemporary  soft- 
ware methodologies.  The  following  figures  show  the 
topologies  cf  each  generation  and  ADA.  ADA's  topology  is 
not  flat  like  those  of  the  previous  generations,  but 
rather    is   multi-dimensional    [Ref-    3]. 


Generation 

1ST 

2ND 

3RD 

GAP 
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Data 


Subprograms 


Figure  4, 1    Topology  for  1st  and  2nd  Generation. 


Figure  4.2    Topology  for  2st  and  3nd  Generation. 
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Figure  4.3        Topology    of    &DA- 


Th€  following  key  features  of  ADA  will  support  the 
tools  for     implementing        the        object      oriented        design 

[Ref.    23]. 

1.  Prcgramoiing    in    the   large. 

Mechanisms  for  encapsulation,  separate  compilation,  and 
library  ttanagement  are  necessary  for  the  writing  of  portable 
and    maintainable  programs  of   any   size. 

2.  Exception  handling. 

large  programs  are  rarely  correct.  It  is  necessary  to 

provide  a   means  whereby  a  program  can  be  constructed   in  a 

layered   and  partitioned  way  so   that  the  conseguences  of 
errors  in  one   part  can  be  contained. 

3.  Data    abstraction. 

Extra  portability  and  maintainability  can  be  obtained 
if  the  details  of  the  representation  of  data  can  be  kept 
separate  frcm  the  specifications  of  the  logical  oprations  on 
the    data. 
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4.  Tasking. 

For  many  application  it  is  important  that  the  program 
ts  ccnceivad  as  a  seriss  of  parallel  activities  rather 
than  just  as  a  single  sequence  of  actions.  Building  appro- 
priate facilities  into  a  language  rather  than  adding  them 
via  calls  to  an  operating  system  gives  better  portability 
and   reliability. 

5.  Generic   units. 

In  many  cases  the  logic  of  part  a  program  is  independent 
of  the  types  of  the  values  being  manipulated.  A  mechanism 
is  therafore  necessary  for  the  creation  of  related  pieces  of 
program  from  a  single  template.  This  is  particularly  useful 
for    the   creation   of    libraries. 
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V-    51    SOLOTIOH 

A-       PBOBIEM    AND    SOLOTIOH 

As  shewn  above,  most  traditional  approaches  to  pretty 
printers  are  for  a  specific  programming  language,  A  recent 
develcpmsnt  is  the  syntax  directed  prerty  printer  that  can 
be  used  for  different  languages  by  providing  a  grammar  of 
the  language.  The  reguirement  -o  provide  a  language  grammar 
represents  a  non-trivial  task.  There  are  many  different 
secondary  objectives  for  a  pretty  printer  for  different 
users.  The  functions  of  a  traditional  pretty  printers  are 
not  enough  to  improve  both  the  readability  and  understand- 
ability  e.g.  the  program  level  construct  documentation  that 
traditicral  approaches  do  not  support  is  needed  to  help  to 
understand  a  given  program.  In  short,  there  are  many 
programming  languages  and  many  purposes,  but  there  is  not  a 
system  that  satisfies  all  those  requests  and  can  be  modified 
easily. 

In  the  previous  section,  the  concept  of  a  program  family 
was  discussed.  The  best  way  to  solve  the  various  demands  and 
many  programming  languages  is  to  construct  a  program  family 
for  the  extended  pretty  printer.  The  characteristics  of 
program  family  will  permit  easy  change,  easy  extension,  and 
easy  contraction.  Each  programming  language  will  have  a 
module  for  itself  and  data  abstraction  and  procedural 
abstraction  will  be  used  to  hide  design  decisions  that  will 
differ  among  the  members  of  the  program  family.  Data  and 
procedural  abstraction  will  also  allow  some  modules  to  be 
used  by  all  program  family  members.  ?or  example,  the  blank 
operations  are  a  important  data  abstraction.  These  oprations 
can    be   used    for   all    fiogramming  languages   and   objectives. 
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B.       GENEBALIZED    PROGBAMHING    LANGUAGE    CONSTBOCT 

Fcr  generalized  indenzation  and  level  documentation,  an 
general  internal  representation  of  program  structure  is 
required  that  is  independent  of  any  particular  programming 
language.  Let  us  call  it  a  qenerali  zed  formatter  stucture. 
Since  there  are  many  programming  language  constructs  in  the 
many  different  programming  languages,  it  is  too  difficult  to 
define  a  perfect  universal  programming  languge  forma-ter 
construct.  So,  we  define  here  a  generalized  programming 
language  formatter  construct  that  can  cover  only  a  limited 
number  of  programming  languages  -  structured  FORTRAN,  PASCAL 
and  seme  ether  structured  programming  languages.  For  simpl- 
icity, the  detailed  representation  of  a  simple  statement 
will    be    emitted. 

The  structure  of  the  program  will  be  shown  by  inden-ing 
the  constructs.  First,  the  control  structure  will  be 
considered.  Dijkstra  argued  that  control  flow  should  be 
limited  tc  three  basic  structures  -  linear  sequence,  struc- 
tured selection,  and  structured  iteration.  But  many  program- 
mers use  the  following  five  struc-ures  -  if,  case,  while, 
until,  dc  for.  Also  the  block  can  be  a  element  of  the  struc- 
ture. Second,  most  program  units  are  divided  into  two  parts: 
a  declarative  part  and  imperative  part.  This  is  also  impor- 
tant for  the  indentation.  The  Appendix  A  describes  in  detail 
the    generalized    format  structures. 
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C.   ANALYSIS  AND  DESIGN 

1 .  Analysis 

The  extended  pretty  printer  has  two  basic  functions. 
The  first  is  to  reformat  the  source  program  a.g. 
indent, insert  spaces  and  linefeeds  between  tokens  and  to 
decide  where  and  how  to  break  lines  that  are  too  long  to  fit 
on  the  output  medium.  The  second  is  to  produce  level  struc- 
ture documer.taticn  of  the  source  program.  The  basic  require- 
ment of  the  total  system  is  that  it  has  to  be  easy  to 
change,  easy  to  extend,  easy  to  contract,  e.g.  it  should  be 
independent  of  the  programming  language  and  should  be  able 
to  fulfill  a  variety  cf  purposes. 

Every  structured  programming  language  can  be  repre- 
sented as  English  is  -  character,  word,  statement,  compound 
statement  (paragraph)  ,  unit  program (a  paper).  What  is  of 
interest  is  the  way  to  represent  these  component  as  lines. 
The  relationship  of  these  components  and  lines  is  very 
important  fcr  the  extended  pretty  printer.  The  following 
table  represents  the  relationship  of  line  and  statement. 
The  other  components  have  some  relation  with  the  state- 
ments. So,  every  component  can  be  represented  by  lines. 

Each  level  is  represented  by  the  source  program 
structures.  The  structures  are  represented  by  statements. 
So,  each  statement  can  have  a  level  degree. 

2 .  Design 

As  noted  in  the  section  on  program  families,  the 
most  important  aspect  of  this  system  design  is  to  identify 
the  objects.  For  the  indentation,  the  line  and  statement  are 
basic  elements.  Blank  is  other  important  object.  For  the 
construct   representation,    level   has   to    be   a   object. 
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TABLE    II 
Relationship  Table 


LINE 

STATEMENT 

on« 

! 

one 

on€ 

1 

many 

one 

1 

part 

on€ 

part  and 
one/many 

("part"    means  part   of   a   statement) 

The  heavily  dependent  parts  should  be  encapsulated 
in  a  module  to  allow  for  easy  change.  The  indentation 
policy  can  he  changed  variously,  it  needs  to  be  manipulated 
independently.  To  manipulate  the  input  programming  languages 
independently,  the  program  should  be  a  indepedent  module. 
The  program  module  needs  some  data  structures  -  STACK, 
QUEUE  -,  Keywords  table,  and  some  statement  oprations.  The 
files  -  input  source  file  and  output  file  -  and  their  format 
can  be  changed  easily.  So,  the  input/output  files  manipula- 
tions   need    be   separated   from   other   modules. 

For  convenience,  the  module  will  be  divided  intc  two 
kinds.  One  is  passive  modules  that  are  used  by  other  modules 
but  that  do  not  use  other  modules,  for  example,  blank, 
level,  stack,  queue  and  line.  The  other  kind  is  active 
modules  that  use  the  other  modules,  for  example,  input, 
output,  program  and  so  on.  ADA  will  be  used  for  the  detailed 
design   of      the    system.  The    following      shows   the      detailed 

design. 
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a.      Passive    mcdules 

0) •  stack  Module.  This  module  provides  some 
stack  opraticns.  And  i-  provides  the  following  procedures 
for    other   modules      that   use    them   [Ref.    2i*]- 


generic   type  ITEM  is    private 
package        STACK  is 

type   LIST    is   private; 

procedure    CREATE  (L:    out   LIST); 

procedure    POSH(L:    in   out   LIST;    I:    in   ITEM); 

procedure    POP(L:   in   out   LIST); 

function      TOP(L:    LIST)     return   ITEM; 

underflow    :    EXCEPTION; 
private        type    NODE; 

type   LIST    is   access   NODE; 

type   NODE    is   reccrd 
head    :    ITEM; 
tail    :    LIST; 

end   reccrd; 
end    STACK; 

(2)  .  2ii§i3§  Mod  ule .  This  module  provides  soma 
QUEUE  oprations.  And  it  provides  rhe  following  procedures 
for    ether   modules  that  use    them   [Ref.    24]. 

generic   type  ITEM   is    private; 
package        QUEUE  is 

type   LIST    is   private; 

procedure    CREATE  (L:    out   LIST); 

procedure    ENQUEUE(L:    in   out    LIST;    I:    in    ITEM); 

—  Insert    the    item    into    the    rear    of    QUEUE 

procedure    DEQUEnE(L:    in    out    LIST;    I:    out    ITEM); 

—  Delete    the    item   from   the    front   of   QUEUE 

underflow    :    EXCEPTION; 
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private        type  NODE; 

type   LIST  is  access    NODE; 

type   NODE  is  record 

head  :    ITEM; 

tail  :    LIST; 
end   record; 
end    QDEDE; 

(3).       Blank    Module.  This    module      provides   all 

blank   operations  that  insert,      remove,        count   and   so   on   for 
other    modules  that    need   the    blank   operations. 


generic   type  INPUT    is   private; 
package        ELANK  is 

ELK      :    constant    CHARACTER    :=    •     '  ; 

type    NUM   is    NATURAL; 

procedure    INSERT(N,M:    in    NUM;    P:    out    INPUT); 
N    :   The   start    column   of  a    line 
M    :    The   number   of    blanks  to    be   inser-ced 

procedure    DELETE(N,M:     in    NUM;    ?:    out    INPUT); 
N    :    The   start   column   of   3.    line 
M    :   The   number   of    blanks  to    be   deleted 

procedure    START  (L:    in    INPUT:    N:    out    NUM)  ; 
N    :   The  number   of    blanks  in   a    line 
from    the   start   column 

function   IS    3LANK(C:    in   CHAR);    rerurn    BOOLEAN; 
Check   ^he    input  character    is    blank 
If  blank,    return    TRUE 
Else,    return  FALSE 

overflow    :     EXCEPTION; 

end    BLANK; 


(U)  .  Level  Module.  This  module  will  provides 
the  level  operations  for  other  modules  that  need  them.  The 
operations   are: 

package        LEVEL  is 
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type    NOM   is    NATDEAL; 

procedure    INCRSAS2(L:  in   ou"^-    NUM)  ; 
Increase   the  level 
L    :    input/curput    level   number 

procedure    DECREASE  (L:in   out    NUM)  ; 
Decrease   the  level 

procedure    ZEROj[L:in   out   NOM)  ; 

Make   rhe    level   zero   or   starting    point. 

overflew   :     EXCEPTION; 

underflow    :    EXCEPTION; 

end    LEVEL; 


(5)  •  LiM  Modu  le.  This  module  manages  the  line 
object.  It  provides  a  set  of  procedures  available  zo  other 
modules   that     use  the  line. 

Generic   type  LINETYPE  is    private; 
package        LINE  is 

type   LINEPOINT    is   privare; 

type    NOM   is    NATURAL; 

type   CHAR    is   CHARACTER; 

procedure    GET    LINE 

IP:    in    out    LIIEPCINT;     L:    out    LINETYPE)  ; 

Get  a    whole   line    into   internal   structure 

P    :    ID   for   a  line 

L    :    Content  of   a    line 

procedure    PUT    LINE 

(P:    in    out    LIrlEPCINT;     L:    in    LINETYPE)  ; 

Put  the   a    internal   line   into   the    linetype 

P    :    ID   for    a  line 

L    :    Content  of   a    line 

procedure    LINE    LENGTH 

(P:    in    LINEPOITIT;    N:    out    NUM)  ; 

Compute  the   line    length 

P    :    ID   for   a  line 

procedure    GET    CHAR 

(P:    in    LINSPOXNT;    N :    in    NUM:    out    CHAR): 

Get   a    character   that    is    in    given   line   and 

PC  si  ton 

F    :    ID   for    a  line 


procedure    POT   CHAR 

(P:    in    LINEPOINT;    N:    in    ITEM:    in   CHAR); 

_  _    _  __    acter   i 

and  the   line  given 


Put  the  given   character   into    the    position 
-  ^    ■  '  -    li:  -      -■     - 
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P  :  ID  for  a  line 

N  :  Column  of  the  line 

procsdura  FRONT  INSERT 

(P:  in  out  LINEPCINT:  L;  in  LINETYPE)  ; 

Insert  line  in  front  of  the  given 

line  position 

P    :    ID   for   a  line 

L    :   Content  of   a    line 

procedure    REAR    INSERT 

^P:    in    cut    LIN'EPOINT;     L:    in    LINETYPE)  ; 

Insert   the    line  at   rear  of 
the  given    line   position 
P    :    ID   for   a  line 
L    :    Content  of   a    line 

underflow    ;    EXCEPTION; 

overflow    :    EXCEPTION; 

private        type    NODE; 

type   LINEPOINT    is   access    NODE; 

type   NODE    is   reccrd 

content         :   LINETYPE; 

front  :    LINEPOINT; 

rear  :    LINEPOINT; 

end   record; 
end    LINE; 


(6)  .      Symbol      Table    Module.  This    module      will 

manage   a   symbol      table.        It   is   designed      for   general   symbol 
manipulation. 


Generic   type  ITEMTYPE  is   private; 
package         SYMBOLTABLE  is 

N    :    constant   =:    200;  —    size   of   symbol   table 

ITEMSIZE:     constant   =:     20; 

type    ITEM    is   new   STRING  (1  ..  ITEMSIZE)  ; 

procedure    ADD(X:in   ITEM;    I:    in    ITEMTYPE); 
Insert   an    item   and   the   information 
associated    with   it    into    SYMBOLTABLE 

functicn  INSTABLE (X :in    ITEM)    return    BOOLEAN; 
Check    to    see  if   an   item   is    m 
the   SYMBOLTABLE 

functicn   GET(X:in   ITEM)    return    ITEMTYPE; 
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Retrieve   the  information  associated 
with    an   item   in   the    SYMBOLTABLE 

function  FULL    return   BOOLEAN; 

Dexermine    whether    or   nor  the    SYMBOLTABLE 
is  full 

crocsdure    CLEAR;  —    empty   table 

--        Reinitialize    (reset)    the  SYilBOLTABLS 

end    SYMBCLTABLE; 


t.      Active    modules 

C )  •      III2.UI   Module.      This    module  hides   the  input 

format.      It    raads        the   original   lines    from  the    input  media 

and      calls    procedures     provided   by     the    line  module   to  stcr? 
the    lines      inside  of   the   line   object. 

with    TEXT_IC; 

with    LINE; 

generic   type  LINEPOINT  is        private; 

package   INPDT  is 

type    INFILETYPE    :   TEXT.IO .FIL3_TYPE; 

procedure    READFILE 

(INFILZ:    in    INFILETYPE:    START    :     out    LINEPOINT)  ; 

Read    the    input   file   and   store    each    line    into 
internal    line   structure   using    LINE   module 
INFILE    :    The   input   file   that   have   source    orcgram 
START      :    The  starting   line    ID    of    internal" 


structure 


end    INPUT 


(2)  .  Output  Module.  This  module  will  hide  the 
outfile  media.  And  it  will  output  the  indented  results,  the 
construct  form  of  the  input  program  and  the  input  using 
other    modules      -   indent,    line    and  so    on. 

with    TEXT.IO; 
with    LINE; 
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with    INDENT; 

generic   type  LINETYPE  is         private; 

package   COTPUT    is 

type    OUTFILETYPE      :    TEXT_IO.  FILE_TYPE  ; 

type    CCDEFILETYPE    :    TE XT_IO. FILE_TYPE ; 

procedure    PRINT    CUTFILE 

(OUTFILE:    out    ITIFILETYPE;    START    :    in    LINEPOINT)  ; 

Print    the    indented  output   into   OUTFILE   using 

indent   and    line  modules 

OUTFILE    :     The    output    fil?    -hat    has 

the   indented    source    prcgram 

START         :     line    start    ID   of    internal    structure 

procedure    PRINT    CODEFILE 

(CODEFILE:     cut    INFILETYPE;    START    :    in    LINEPOINT); 

Print    the    code   documentation   using    line   and 

indent   module 

CODEFILE    :    The   output    file    that    has 
the    code    documentation 

START  :    Line  start   ID  of    internal   structure 

end   OUTPUT 


(3) .  Statement  Module.  This  module  manages  the 
statement  object  and  also  provide  a  set  of  procedures  avai- 
lable to  other  modules  that  use  the  statement  object  by 
using   lire    module    procedures. 

With    LINE; 
generic 

type    INDENTPOINT   is   private; 
package        STATEMENT    is 

type    NUM   is    NATURAL; 

type    CHAR    is    CHARACTER; 

type    INDENTPOINT    is   access    INDENTNODE; 

type   STATEPOINT    is    access    NODE; 

type   NODE    is   record 

content         :    STATETYPE; 
front  :    STATEPOINT; 

rear  :    STATEPOINT; 

end    record; 
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type  SIATETYPE  is  record 

from  :  POSITION; 

tc  :  POSITION; 

information  :    INDENTPOINT; 

end   record; 

type   POSITION  is  record 

lina  :   LINEPCINT; 

column  :   NUM; 

end   record; 

procsdure    GET_STflTE    DELIMITOR(D:    in    CHAR); 
Get  statement   delimiter 

function    END  OF    STATE (D:    CHAR)     return    BOOLEAN; 
Checlt    tHe    end   of    a   statement 

procedure    GET    STATE 

(P:    in    out    STITEPCINT;     L:    out   STATETYPE)  ; 
Get   a    statement   using  LINE    module 

procedure    POT   STATE 

(P:    in    ou-    STlTEPOINT;     L:    in    STATETYPE); 
Put  a    statement  using   LINE    module 

procedure    STATE    LENGTH 

(P:    in    STATEPOITJT:    N:    out    NUM)  ; 

Compute  the  length  of   a   given   statement 

procedure    RECOGNIZE    STATEMENT 
(P:    in    out    ST  AT  EPOITTT;     L:    in   LINEPOINT)  ; 

Recognize    the   statement   from 

the  internal  line    structure 


procedure    GET   CHAR 
(P:    in    STATEPDINT;    N:     in    NUM:    ouz    CHAR); 

Get  a    character   from   the 

and  column 


given    staremen- 


procedure    PUT   CHAR 

(P:    in    STATEPDINT;    N:     in    NUM: 

Put  a    character  into   the 

and  column 


in   CHAR) ; 
given    statement 


procedure    FRONT   INSERT 

(P:    in    out    STATlPOINT;    L:    in    STATETYPE); 
Insert   the    given    statement    into 
front    of    the  given    statement   ID 

procedure    REAR    INSERT 

(P:    in    out    STATEPOINT;    L:    in    STATETYPE); 
Insert  the    given    statement    iaro 
rear    of  the  given    statement   ID 

underflow    :    EXCEPTION; 

overflow    :     EXCEPTION; 

end    STATEMENT; 
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(4)  .      Indent   Module.  This   module      will   indent 

each  line  using  the  line  module,  statement  module  and  tlank 
module.  And  the  indentation  policy  can  be  decided  here  e.g. 
the    size    cf   each   level,    the    treatment   of   blanlcs,    and   so   on. 

with  BLANK; 

with  STATEMENT; 

wirh  LINE; 

generic   type  POLICYTYPE   is    private; 

type   CCNSTRUCTTYEE    is    private; 
package        INDENT  is 

type    INDENTPOINT    is    access    INDENTNODE; 

type   INDENTNODE  is    record 

level  :    NUM; 

constrcut     :    CONSTROCTTYPE; 

end    record; 

procedure    INDENT 

(P;    in    STATEPOINT;    L:     out    LINETYPE)  ; 

Indent   a    line    i.e.    insert    or   delete   blanks 
and   make    line   break   according    to   th?  source 
program  syntex   using  the   information   about 
level    and    ccnsrruc-    type   and   so    on 

procedure    GET    PCLICY 

(P:    in    POLICYTYPE)  ; 

Get  the   indentation    and  objective   policies 
for  example,   each    level    has    3    blanks 
and  with    inaentation   error    messages. 

procedure    POT    POLICY 
(P;    cut   POLICYTYFE)  ; 

Put  the   indentation   and  objective   policies 

procedure    GET    INFORMATION 

(P:    in    STATEPOINT;    L:     out    STATETYPE)  ; 

Get  the   information    for   indentation 

and  level    dccumentation 

procedure    PUT    INFORMATION 

(P;    in    STATEPT5INT;    L:     in    STATETYPE)  ; 

Put  the   information    for   indentation 

and   level    documentation 

end    INDENT; 
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(5)  •  P^c^ram  Module.  This  module  will  hide  the 
program  characteristics.  It  should  be  highly  dependent  on 
each  programming  language.  It  have  two  procedures  -  scanner 
and  parser. 


with  LINE; 

with  STATEMENT; 

with  ELANK; 

with    SYMECLTABLE; 

with    LEVEL; 

with    STACK; 

with    QUEUE; 

package         FEOGRAMPART        is 

procedure    SCANNER 

(P:    in    out    STATEPOINT;     L:    out   ITEMTYPE)  ; 

Scan    the    source   program  and   recognize 
each    statement   type    for  parser 

procedure    PARSER; 

Recognize   the   construct   of   the   source 
program 

end    PROGEAMFART; 


(6)  .      Master    Module.        This      module    will  control 
all    above   mcdules. 


with    PROGRAMPAHT; 

with    INDENT; 

with    INPDT; 

with    CUTEUT; 

procedure    MASTER; 

Control   all   the   module   for   reformatting 
and  level    structure   documentation 
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Module  Interface- 


The  above    figure  explain   the   inxarfaces   of 
each    module.   The   arrow  direction    indicates    using    module. 

D.       EXAMPLE     (FORTRAN) 

1 .      Standard   Form 

There      have  been      many   attempts      to  standardize      the 

FORTRAN    programming  language.      Here,    the   standard      form   will 

follow      the    concept  of    COMPATIBLE      FORTRAN   [ Ref .     1]-           The 

following   represent  the   rough   standard    form. 
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a.      Basic  Components 

It  consists  of  four  elanients  -  character  set, 
symbolic   names,    constants   and   array    elements. 

t-      Statements 

(1)  .  Statement  Components.  Sta^iements  are  made 
up  of  such  components  as  labels,  keywords,  symbolic  names, 
constants  and  special  characters.  For  Compatible  FORTRAN,  a 
stricter  rule  should  be  observed:  (1).  Statement  labels, 
keywords,  symbolic  names,  integer  constants  should  not  have 
embedded  blanks,  except  for  key  words  GO  TO,  DOUBLE 
PRECISION  and  BLOCK  LATA,  which  may  have  blanks  in  the  posi- 
tions shewn.  (2)  .  Where  two  alphabetic  or  numeric  state- 
ment components  ccme  together  with  no  other  special 
characters  between  them,  a  blank  should  be  inserted.  Example 
are: 

CO15I=1,10  DO    15    1=1,15 

REWINDJ  should    be    written  REWIND   J 

REALAAA  REAL    AAA 

(3)     Keywords,    labels,   symbolic    names    or   constants    should    not 

be   split   between  two    lines. 

(2)  .  END  Line.  END  is  not  considered  a  state- 
ment but  is  a  type  of  line.  It  may  not  be  labelled,  executed 
or  continued.  Note  especially  tha-  END  is  not  an  executable 
statement  with  the  same  effect  as  RETURN  in  a  subrprcgrara  or 
STOP    in    the    main   program. 

(3)  .  Format  2^  Statemenrs.  The  Standard  limits 
each  statement  to  cne  initial  line  and  not  more  than  3 
continuation  lines. 

C^)  •  Order  of  Statements.  The  following  table 
show  the  order  of  statements.  By  'header  statement'  is  meant 
a  SUBROUTINE,  FUNCTION  or  BLOCK  DATA  statememt.  Horizontal 
lines  within  the  table  indicate  that  entities  above  the 
line      must    precede      entities   below      the      line    (if      present) . 
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TABLE    III 
Table  of    Statement    Order 


Header  Statement 
Type    Statements 


Comment 
Lines 


DIMENSION  Statements 
COMMON  Statements 


FORMAT   Statements 
END    line 


EXTERNAL 
Statements 


EQUIVALENCE    Statements 

DATA    Statements 

Statement   Functions 

Executable    Statements 

STOP   line 

Vertical   lines    indicate   that   the      entities    on   either   side   of 
the    line    may  be    intermingled  [Ref.    1]. 

c.  Specification   Statamants 

Specification  statements  are  non-executable 
statements  which  give  information  to  the  compiler.  It 
consists  of  T?PE  (DOOELE  PRECISION,  INTEGER,  REAL,  LOGICAL, 
and    COMPLEX),    DIMENSION,    COMMON,     DATA    and    EQUIVALENCE. 

d.  Transfer   of   Control 

This   consists   of  the  GO    TO    statement.      Computed 

GO   TO   statement,    RETURN   and    STOP  statements,      Arithemetic   IF 

statement.    Logical    IF  statement,  DO   statement,      and   CONTINUE 
statement. 
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€.      Input/Output 

This  consists  of  the  WRITE  statement,  READ 
statemenx,  ENDFILE  statement,  REWIND  statement,  EACKSPACE 
statement   and  FORMAT    statement. 

f.  Expressicn  and  Assignment 

This  consists  of  the  Arithemezic  Expression, 
Logical   expressicn,    and   Assignment  sta-cement. 

g.  Program    Units 

This  consists  of  the  Main  program.  Function 
subprograms.    Block    Data,    and   Subroutine   subprograms. 

2  •      Structured   F crm 

The  algorithm  language  [Hef.  18]  is  convenient  for 
representing  the  generalized  construct  structure.  So,  to 
represent  the  structured  FORTRAN  form,  it  will  be  compared 
with  the  algorithm  language.  Detail  structured  forms  are  as 
follows : 


ALGORITHM    LiNGU AGE  FORTRAN    17 

1.  ALGCEITHM 

ALGORITHM   a Igor i th m__ name  same   with    'C    in    column    1 

statements 
END    algcrithiE^name 

2.  IF_THEN_single    statement 

IF  condition  THEN  IF  (condition)  statement 

statement 
END  IF 

3.  IF_THEN_inultiple   statements 

IF   condition  THEN  IF    (.NOT.    condition)     GO  TO    10 

statements  statements 

END    IF  10    CONTINUE 

4.  IF_TEEN_ELSE   construct 

IF  condition  THEN  IF  (.NOT.  condition)  GO  TO  5 
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statements  1 
ELSE 

statements  2 
END  IF 


statements  1 
GO  TO  6 

5  CCNTINaE 

sratement    2 

6  CONTINUE 


5.         Multiway  selection    :    ELSE   I? 


IF    continus_1    THEN 

statements  1 
ELSE    IF    conditi5n_2    THEN 

statements  2 
ELSE    IF    condition_3    THEN 

statements  3 
ELSE 

statements  4 
END    IF 

(ELSE   is   optional) 


IF    (.NOT.    conditional)    GO   TO    10 

statements    1 
GO    TO    2  0 

10  IF    (.NOT.    condition_2)    GO  TO    11 

statements    2 
GO    TO    20 

11  IF     (.NOT.    condition_3)     GO   TO    12 

statements   3 
GO    TO    2  0 

12  CONTINUE 

statements   4 
20    CONTINUE 


6.         WHILE   repetion 

WHILE    condition    DO 

statements 
END    WHILE 


5  IF    (.NOT.    condition)     GO   TO   6 

statements 
GO    TO    5 

6  CONTINUE 


7.         REPEAT   repetition 

REPEAT 

statement  s 
UNTIL  condition 


5    CONTINUE 

sratements 
IF     (.NOT.    condition)     GO    TC    5 


8. 


DO   FOR   repetition 


FOR    I    <-    L    TO    M    BY    N    DO 

Statements 
END    FOR 

(BY    N   can    be  omitted,    in 
which   case    EY    1    is    assumed) 


DO    10    I    =    L,M,U 

statements 
10    CONTINUE 

(, N   can    be   omitted    in    which   case 
, 1    is    assumed) 


9.         Multiway  selection  _  CASE 


CASE    variable  OF 
1: 

statements    1 
2: 

3: 

ELSE 

Statements   4 
ELSE    CASE 

(ELSE    is    optional) 


statements_2 
statements    3 


IF  (variable. LT.1)  GO  TO  20 
IF  ivariable.GT.3)  GO  TO  20 
GO    TO     (11,12,13),    variable 


I     ( 

11  CONTINUE 

statements    1 
vGO    TO    3  0 

12  CONTINUE 

statements   2 
GO    TO    3  0 

13  CONTINUE 

Statements  3 
20  CONTINUE 

statements  4 
30  CONTINUE 


10.   FDNCTICN 

FUNCTION  function  na me (parm_1 , . . .  ,  parm_n) 
statements  "" 
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functicn_na  me    expression 
END    f unction^narae  "* 

data    type    FUNCTION   f  anction_naine  (parm    1,...,parin  n) 
statements  ~  ~ 

functior   name   =    expression 
RETURN      ~ 

END 

11.        EROCEDURE     (SUBRCCTINE) 

EROCEEURE   procedur 9_name  (parm__1 , . . . ,    parin_n) 

statements 
END    procsdur€_name 

SUBROUTINE    subroutine_name (parm_1 , . . . ,    parm_n) 

statements 

RETURN 
END 


3.      Format    Grammar 

This  grammar  represents  the  construct  format  of 
structured  FORTRAN.  It  is  a  subset  of  r:he  genaralized  format 
structure.  The  control  structure  is  limi-ed  to  5  structures 
-  if,  case,  whils,  until,  and  do.  In  the  declaration  part, 
the  declarations  will  be  statements.  For  more  detail,  the 
grammer      figures    (Appendix    B)    can    be    referenced. 

^ •      Ijplementaticn 

a.      Limitations 

An  ADA  ccmplier  was  not  available  for  this  work. 
So,  the  PASCAL  programming  language  was  used  to  inplement 
the  system.  This  iirplemen tation  is  a  little  different  from 
the  design  of  the  previous  section  because  PASCAL  does  nor 
support  all  the  ADA  programming  features.  In  order  to  simply 
the  implementation,  just  a  subset  of  the  system  was  imple- 
mented,   i.e.      the  UNTIL   construct   is    omitted. 

Also  the  implemented  system  does  not  cover  all 
standard  FORTRAN  -  it  does  not  include  some  keywords  like 
PAUSE,    REWIND  and   so    en.         The   other    limitations    of   this   are 
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the  fcllcwing:  1.  All  input  programs  should  be  syntatically 
correct  to  get  proper  indentation  and  the  level  documenta- 
tion. 2.  All  input  FORTHAN  programs  should  be  conform  tc 
the  standard  structured  form  mentioned  in  previous  sections. 
3.  The  input  lines  should  be  short  enough  to  indent  without 
being  extended  onto  the  next  line.  That  is  the  implemented 
system   does   not    have   the   line    break   function. 

b.      Internal    Data   Structure 

C)  •  liiUS  Data  Structure .  The  input  line  and 
output  line  are  represented  as  an  array  of  characters. 
Normally,  programming  langugages  use  80  column  per  line.  In 
actual  programs,  most  lines  do  not  use  all  of  the  columns; 
the  mean  cf  programming  line  size  is  34  [Ref-  2].  If  the 
maximum  array  is  assigned  for  one  line,  space  is  wasted.  So 
to  save  memory  and  make  the  line  flexible,  a  double  linked 
data  structure  was  used  for  the  internal  line  structure. 
Also,  a  sentinel  node  will  be  used.  It  allows  an  easy  check 
of   an   empty    input   file. 

(2)  •  Statement  Data  Structure .  As  shown  above, 
the  relationship  of  line  and  statement  is  one  to  one  or  many 
to  one.  Clearly,  the  statement  can  be  represented  by  the 
line  data  structure.  So,  a  line  record  will  have  information 
about   statements.  Comment   statements   will    be      ignored   for 

statement   representation. 

(3) .      Construct    Data    Structure.  The   construct 

will  have  seme  relationship  with  the  statements  e.g.  one  to 
one  for  simple  statements,  one  to  many  for  others.  The 
statements  can  have  the  information  of  the  construct,  since 
every  construct  can  be  seperated  into  statements.  For 
example,  the  DO  construct  consist  of  DO_COND  statement, 
compound  statement  and  2ND_D0  statement.  But  here,  the  line 
also  will  have  the  construct  information.  It  is  possible 
since  the  relationship  of  line  and  statement  also  one  to  one 
and    many   to   one. 
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c.      The    Program   and    Example   Input/Output 

Anyone  interested  in  obtaining  a  copy  of  the 
program  should  contact  the  author  directly  or  the  Computer 
Science  Department  at  the  Naval  Postgraduate  School, 
Monterey,  California.  The  example  input  output  can  be 
referenced  in  Appendix  C.  The  example  program  does  not  have 
any  meaning.  It  is  written  just  to  show  the  constructs  of 
programs    and  the   results   of    program   execution. 
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71.  CONCLOSION 

One  of  today's  software  problems  is  the  very  high  cost 
of  develcpirg  and  maintaining  software.  Much  research  has 
been    devoted     to   solving     this    problem.  One   way      to    solve 

today's  software  crisis  is  to  study  software  tools  that  can 
help    people    who    serve   in   the   software   area. 

This  thesis  designed  and  partially  implemented  a  program 
family  of  extended  pretry  printers  that  can  help  to  solve 
software  problems  by  improving  readability  and  understand- 
ability    cf    programs. 

The  system  will  worlc  for  almost  any  structured  program- 
ming language  and  for  various  secondary  functions  with  only 
small  changes  in  some  modules.  The  design  presented  here  is 
for  a  program  family  cf  pretty  printers.  The  program  imple- 
mented her9  is  one  member  in  this  family.  Other  members  of 
the    program   family    remain  tc   be   implemented. 
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APPENDIX    A 
GENERALIZED   CONSTBOCT    FLOH   CHART 


On <" 


PROG   HEAD 


V_ 


^ 


~\ 


->0 


Figare    1.1         Progran  Structure. 
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Figure   A. 2        Declaration. 


O >(^  SUB_HEAD    ^ ^  MAIN 
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Figure   a. 3        Subprocedure. 


»(  Ef-p_s"   J — k:) 


Figure   A. 4        Main  Procedure, 
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Figure    A. 5        Compound  Statement. 
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Figure   A. 6        If   Statement. 
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Figure  A. 7        Case  Statement. 
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Figure   A. 8        Ihile  Statement, 
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Figure  A. 10        Do   Statement- 
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Figure  A. 11    Block  Statement. 
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APPENDIX    B 
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Figure    B-3        Main. 
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Figure   B-4        Compound  Statement. 
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Figure   B.5        If   Statement. 
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Figure  B.6        Case  Statement. 
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Figure   B.  7        while  Stateaent, 
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Figure  B. 8        Until  Statement, 
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Figure   B. 9        Do   Statenent- 
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Figure   B.  10        Case^Cond. 


}  O ►CgO_LABEL     3 ^  LABEL_IF    ^ ^ 

I 


r 


I 


Figure    B.11        Go_If. 
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Figure  B.12        Go_Cont. 
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Figure  B.13        State  Chart    1. 
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Figure  B-14        Stata  Chart   2- 
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Figure  B.15        State   Chart   3. 
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Figure  B.16   Continaation  of  State  Chart  3. 
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APPENDIX  C 
EXAMPLE  OF  INPOT  AHD  OOTPOT 


***  INPUT  NOT  INDENTED  * ** 


(3**  *«**4e  *«*♦****«:(:  *♦*♦*****  :»*:«£***♦*************** 

C***   TEST  PBOGRAM  FCF  THE  AUTOMATIC  ************ 
C***   INDENTATION  PRCGRAM  ************ 

C***  ************ 

Q*********** ************ ************************* 

c 
c 

c*** ************  ***********  ********************** 

C  MAIN    PROGRAM 

(^**  *********************  ************************* 

C 

C***       DECLARATION 

C 

R^AL    R1,  R2,R3r  RC(20) 

INTEGER    11  ,12,13, ID(20) 

LOGICAL    LI ,L2,L3 
C 

C***       CCMECUND    STATEMENT 
C 

C  SIMPLE    STATEMENT 

C  IF    STATEMENT 

C  CASE    STATEMENT 

C  SHILE    STATEMNET 

C  CO    STATEMENT 

C 
C 

READ(5J00)     11,12,13 
100    PCFMAT(3I5 

LI    =     .TRUE. 

R1  =  1.5 
1+5.0-6.7 
2  +  4.8 

CALL    SUB{RD,ID) 

IE  (.NOT.  (II.  NE.  1)  )     GO    TO    1 

DO    500    I    =    1,20 

R(I)=0.0 
500    CONTINUE 

GO    TO    444 

1  IE  (.NOT.  (12. NE. 2))     GO    TO    2 
1  1  1    IF    .NCT.     LI)     GO    TO    11 

11=11+1 
GO    TO    11  1 
11    CONTINUE 
GO    TO    444 

2  IF  (I3.NE.3)    GO    TO    3 
12=12+1 

GO    TO    44  4 

3  CCNTINOE 
13=13+1 

444    CONTINUE 
R  (II)  =5.5 

IF  (II .LT.5)     GO    TO    555 
IF  (I1.GT.3)    GO    TO    555 
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GO 


TO  (5,6,7) 


5  CONTINUE 
RD  (1)  =5.  0 
RD  2  =5.0 
GO  TO  656 

6  CONTINUE 
RD  (1)  =6.  0 
RD  (2  =6.  0 
GO  TO  66  6 

7  CONTINUE 

DO  567  1=1-19 
RD(I)  =FLOAT(I) 

567  CONTINUE 

RD  (20)  =40.  0 

555  CONTINUE 

Ri=a.9 

11=4*12 

STOP 
END 


C 

c 

c 

C 

C 

c***« 

c 

c*** 

c 


♦  *♦««♦  «********:«t«**  ******  *********  ********** 

SUE50UTINE  PROGRAM 
******************************************** 

SUBROUTINE  SUB(RD,ID) 
DECLARATION 


C 

c*** 
c 

100 


c 
c*** 

(3*** 

c 


REAL  R1,  R2,R3,  RE(20) 
INTEGER  II  ,12,13,10(20) 
LOGICAL  LI ,L2, L3 

SIKEIE  STATEMENT 

REflC(5,100)  11,12,13 
FORMAT  (315) 
LI  =  .TRUE. 
R1  =  1.5 

IF  STATEMENT 
CO  STATEMENT 

IF  (.NOT.  (II. NE.  1)  )  GO  TO  1 

DO  500  I  =  1,20 

H  (I)_=0.0 

CONTINUE 

RETURN 

END 


***  END  OF  INPUT  *** 
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***  PROGRAM  CONSTRUCT  *** 


DECLA5ATICN 

DECIARATICN 

DECLARATION 

SIKFLE 

SIMPLE 

SIMPLE 

SIMPLE 

SIKPLE 

IF  (COND) 

DO  ( 

END 
ELSE  IF  ( 
WHIL 

END 
ELSE  IF  ( 

SIMP 
ELSE 

SIMP 
END  IF 
SIKPLE 
CASE   VAR 
CONST  : 

SIMP 

SIMP 
CCNSI  : 

SIM? 

SIMP 
CONST  : 

DO  ( 


END 
SI«F 
SIMP 
STOP 

END  OF  PR 

SUEBOUTIN 

DECLARATI 

DECLARATI 

DECLARATI 

SIKP 

SIMP 

SIJ*? 

SIMP 

I?  ( 


RETURN 
END  OF 


END 
SIMP 

CASE 

LE 

LE 

OGRAM 
E 

CN 
CN 
ON 
IE 
LE 
LE 
LE 

COND) 
DO  ( 

END 


THEN 
COND) 

SIMPLE 
DO 

COND) 
E  (CCND) 

SIMPLE 
WHILE 
COND) 
LE 

LE 


LE 

LB 

LE 
LE 

COND) 

SIMPLE 
DO 
LE 


DO 


THEN 
COND) 

SIMP 
DO 


LE 


PROGRAM 


***  END  OF  CONSTRUCT  *** 
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***    OUTPDT   INDENTED    *** 


C****5jt:<i  ♦«««♦****«***  *******  ********************** 
p:(c:4c;{c  :ic  ^  :^  ifci^  i^  ^c  ^  i^^  ^  i^ 

C***       TESI    PROGRAM    FOR    THE    AUTOMATIC    ************ 
C*«*       INDENTATION    PROGRAM  ************ 

C***  ************ 

(;**************************  ********************** 

C 

C 

C*** ****************  *******  ********************** 

C  MAIN    ffiOGRAM 

C*** **************  *********  ********************** 

C 

C***       DECLARATION 

C 

REAI    R1,R2,R3,RD(20) 

INTEGER    II  ,12,  I3,ID(20) 

LOGICAL    LI ,L2, 13 
C 

C***      COMPOUND    STATEMENT 
C 

C  SIMPLE    STATEMENT 

C  IF    STATEMENT 

C  CASE    STATEMENT 

C  WHILE    STATEMNET 

C  DO    STATEMENT 

C 
C 

READ(5,100)    11,12,13 
100  F0RMAT(3I5) 

II    =     .TRUE. 
R1    =     1.5 

1  +5,0-6.7 

2  +U.8 

CALL    SUB  (RE, ID) 
IF(.N0T.]l1.NE. 1 ) )     GO    TO    1 
DO    5  00    I    =     1,2  0 
Rri)=0  .0 
50  0  CONTINUE 

GO    TO    444 

1  IF{. NOT.  (I2.NE.2)  )     GO    TO    2 
111  IF (. NOT.     LI )     GO    TO    1 1 

11=11+1 
GO    TC    111 
11  CONTINUE 

GO   TO    444 

2  IF{I3.NE.  3)     GO    TO    3 

12=12+1 
GO   TO    444 

3  CONTINUE 

13=13+1 
444  CONTINUE 

R  (II)  =5.  5 

IF(I1  .LT.  5)  GO  TO  555 
IF(I1  .GT.  3)  GO  TO  555 
GO   TO    (5,6,7) 

5  CONTINUE 

RD  ( 1 )  =5 .  0 
RDJ2    =5.0 
GO    TO    666 

6  CONTINUE 

RD  (1)=6. 0 
RDi2) =6. 0 
GO    TO    666 

7  CONTINUE 
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567 
555 


STOP 
END 


DO    567   1=1,  19 

RD(I)  =  FLO  AT  (I) 

CONTINUE 

RD(20)=40.0 
CONTINUE 
R1=4.  9 
11=4*12 


C 

c 
c 

c 

C  SUEBODTINE    PROGFAM 

C*  **********************  :«t4t  *******************:«£*** 

SUBROUTINE    SUB  (RD,ID) 


C 

c 


c 

C 


DECLARATION 

REAL  R1,R2rR3,RD(20) 
INTEGER  II  ,12,  I3,ID(20) 
LOGICAL  LI ,L2, 13 


100 


SIMPLE   STATEMENT 
READ  (5,  10  gj 


FORMATr3l5 
LI    =     .TRUE. 
R1   =     1.5 
C 

C***    IF    STATEMENT 
C***    DO    STATEMENT 


11,12,13 


IF(.NOT.  (I1.NS. 1 ))     GO    TO    1 
DO    500    I    =     1.20 


RETURN 
END 


CONT 


R(I)=0  .6 

INUE 


***    END    OF   OUTPUT    *** 
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